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Abstract 

Guidelines  are  presented  for  the  evaluation  and  selection  of 
hardware  and  system  software  for  minicomputers.  The 
evaluation  is  presented  from  a  non-technical  user  point  of 
view  as  opposed  to  a  detailed  technical  comparison.  The 
issues  covered  include  defining  an  approach  for  computing, 
acquiring  a  minicomputer  system,  negotiation  with  vendors, 
installation  and  operation.  Case  examples  are  given  along 
with  examples  of  failure. 


1.  Introduction 

Computer  usage  is  increasing  on  a  national  level.  The  variety  of  approaches  to 
obtain  access  to  computers  has  proliferated.  They  include  the  use  of 
mainframe  computers,  personal  calculators/microcomputers,  distributed 
systems,  and  minicomputers.  Each  of  these  has  potential  appeal  with  a  slightly 
different  audience.  This  report  focuses  attention  on  minicomputers  and 
application  software  and  development  using  minis.  Minis  in  this  report  are 
business  computers  which  can  be  installed  in  user  environments.  The  specific 
purposes  are  to  answer  the  following  questions: 

o  What  guidelines  are  necessary  for  adequately  evaluating  and  selecting 
minicomputers  systems? 

o  What  are  the  potential  costs,  benefits,  and  risks  in  acquiring  such 
systems? 

This  paper  does  riot  select  a  particular  solution;  it  does  not  compare  vendors  or 
products.  Rather  it  provides  a  method  to  aid  potential  users  in  their  own 
evaluation.  It  emphasizes  the  selection  of  a  minicomputer  and  vendor  develop¬ 
ment  and  installation  of  software. 

The  methodology  addresses  the  life  cycle  of  acquisition  defined  by: 

o  Definition  of  requirements  -  determining  the  user  and  system  needs; 


o  Analysis  of  available  system  solutions  -  selecting  the  general  direction 
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and  approach  among  various  minicomputer,  internal  computer,  and 
outside  timesharing  alternatives; 

o  Vendor  selection  -  selecting  a  vendor  lor  a  minicomputer  alternative; 

o  Contract  negotiation  -  reaching  an  agreement  with  a  vendor 

o  Project  plan  and  development  -  planning  and  monitoring  vendor  efforts 
(assumes  using  a  turnkey  or  limited  development  approach); 

o  Installation  and  maintenance  -  implementing,  operating  and  main¬ 
taining  a  minicomputer  system. 

The  time  necessary  to  do  all  this  depends  on  the  project  and  the  extent  of 

development. 

The  audience  for  the  guidelines  is  threefold. 

o  Coordinators  who  provide  counseling  to  user  organizations 

o  Systems  groups  who  might  find  the  guidelines  useful  in  providing 
analysis  and  support  for  inexperienced  user  groups 

o  Non-data  processing  staff  who  do  have  substantial  computer  exposure, 
experience,  and  knowledge. 

The  style  and  approach  in  the  guidelines  Is  from  the  view  of  a  person  who  has 
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limited  EDP  knowledge.  No  extensive  computer  knowledge  is  assumed. 

For  background  and  to  obtain  further  information,  an  appendix  has  been 
developed.  The  appendix  presents  a  discussion  of  the  minicomputer  industry. 


2.  Defining  User  and  System  Requirements 


It  is  important  to  define  needs  in  terms  of  functions,  performance  and  cost. 
This  is  similar  to  the  way  a  consumer  approaches  the  purchase  of  an  auto¬ 
mobile.  Among  these  factors  is  often  a  dominant  problem  which  must  be 
addressed  from  a  business  point  of  view.  For  example: 

o  The  current  system  running  on  a  computer  is  too  expensive,  too  slow  in 
response  time  for  the  business  need. 

o  The  desired  application  software  is  not  available  on  the  computer. 

o  Particular  hardware  or  system  software  features  are  not  available  on 
the  internal  computer  hardware. 

o  There  is  insufficient  time,  money  or  other  resources  to  develop  the 
system  internally. 

The  needs  of  the  user  organization  should  be  specified  in  some  detail.  A  list  of 
typical  user  requirements  is  shown  in  Figure  1.  This  can  be  used  as  a  checklist. 

The  figure  contains  questions  which  identify  the  application,  the  system  users, 
the  system  environment,  operations,  and  cost  and  performance.  Identifying 
characteristics  of  users  can  pin  down  factors  relating  to  terminals  and  terminal 
activity.  The  nature  of  the  business  application  is  defined  in  terms  of  current 
operations  and  procedures  as  well  as  future  desired  requirements.  Describing 


the  system  environment  leads  to  determining  support  requirements.  Ongoing 
staffing  and  support  requirements  are  addressed  on  the  operation  of  the  system. 


The  major  questions  on  cost  and  performance  are  asked  in  Figure  1.  The  cost 
question  is  complex  since  the  equipment  may  be  leased  or  purchased;  the 
investment  tax  credit  may  apply;  accounting  policies  vary  on  amortization  and 
capitalization. 

Once  these  questions  have  been  asked,  the  next  step  is  to  attempt  to  translate 
these  user  requirements  into  system  requirements.  Although  this  almost  always 
requires  systems  expertise  it  is  helpful  to  list  some  system  requirements  that 
may  emerge.  These  appear  in  Figure  2.  If  the  vendor  identifies  the  system 
requirements,  then  these  are  in  the  vendor  proposal. 
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FIGURE  1.  Checklist  of  User  Requirements 


The  Users  of  the  System 

What  are  the  characteristics  of  users  of  the  minicomputer  system? 

o  Number  of  simultaneous  terminal  users  (average,  maximum  number  of 
terminals  active  during  peak  periods) 
o  Physical  location  of  users  (in  a  contiguous  area  or  spread  out) 
o  Maximum  number  of  users  active  with  each  applications 
o  Level  of  experience/expertise  of  users 
0  Specific  functions  that  must  be  supported  by  terminals 
o  Print  quantity 

The  Nature  of  the  Business  Applications 

What  are  the  business  functions  to  be  performed  on  the  minicomputer 
(special  and  general  purpose)? 

o  Information  flow,  files  and  data  elements,  retrieval/inquiry  capability, 
input,  output  (reports,  files),  controls  and  auditing  procedures  of 
current  system. 

o  Desired  changes/additions/deletions  for  new  system. 

Is  there  a  need  to  support  an  existing  application(s)  on  the  minicomputer? 
If  so,  what  are  its  requirements  now  (language  used,  hardware  needed, 
etc.)? 

Are  the  applications  likely  to  change  much  over  time  with  respect  to: 

o  Number,  location  of  users  and  terminals 
o  Amount  of  information  being  input,  stored,  or  printed 
o  Functions  and  features  of  the  application 

What  is  the  relationship  between  applications? 

o  Are  files  shared? 

o  What  applications  are  to  be  operated  simultaneously? 
o  What  interfaces  with  internal  data  centers  are  required? 

The  Environment  of  the  System 

What  is  the  physical  environment  of  the  minicomputer? 

o  Desired  location  of  equipment,  terminals 
o  Dust/dirt  conditions 

o  Air  conditioning/power  available  (business,  non-business  hours) 
o  Floor  space  available  for  system/need  for  raised  floor 
o  Storage  facilities  for  supplies 
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Figure  1  (cont.) 

What  security  control  are  needed  by  the  business  applications? 


o  Physical  access  to  minicomputer 
o  Fire,  flood,  earthquake  protection  needed 
o  Backup  copies  of  input,  computer  files,  output 

<».  The  Operation  of  the  System 

How  many  and  what  kind  of  people  are  needed  to  operate  the  system? 

Who  is  available  to  manage  the  minicomputer? 

Who  will  maintain  the  system? 

How  is  data  to  be  collected? 

\ 

How  will  reports  be  controlled  and  distributed? 

Will  the  system  need  to  communicate  with  other  computers  by 

o  Tape/disk/diskette  transfer 
o  Communication  link 

5.  The  Cost  and  Performance 

What  is  the  cost  ceiling? 

What  are  requirements  for: 

o  Accuracy,  error  rate  (extent  of  editing  needed,  rework  and  correction 
procedures,  audit  controls) 

o  Response  time  (average  and  peak  times  for  response  by  system  to 
terminal  input  by  users) 

o  Volume  characteristics  (average  and  peak  load  of  input  transactions, 
file  access  and  reports) 

o  Availability  (times  when  the  system  must  be  available  for  access) 


FIGURE  2.  System  Requirements 


1.  Hardware 

Printers 

o  Estimated  number  of  lines  per  unit  time  and  required  print  speed 
o  Number  of  printers 

Memory  size 

o  Estimated  size  of  memory,  expansion  limits 
o  Constraints  on  speed  (estimated) 

Disk,  diskette,  tape 

o  Type,  number  of  devices 
o  Capacity-estimated,  limits 

Terminals 

o  Number,  type  of  terminals 

o  Intelligence  features  (editing,  special  feature  key,  etc.) 
o  Speed,  display  size  (CRTs),  print  quality  (hardcopy  terminal) 

2.  System  Software 

Operating  system 

o  Support  of  multitasking,  multiprogramming  (supporting  multiple  users 
and  applications  concurrently) 
o  Ease  of  use,  generation  (set  up,  take  down) 
o  Terminal  communication  support 

Utilities 

o  Sort,  merge,  search 
0  File  management 
o  System  monitoring/reporting 
o  Aids  for  program  development 

o  Aids  for  data  entry/screen  mapping/inquiry 

Compilers 

o  Languages  supported 

o  Compatibility  with  those  on  large  computers  (ANSI  level  supported) 
o  Debugging/ test  data  generation  aids 

o  General  capabilities  (reentrant  code,  ease  of  use,  debugging  aids,  etc.) 
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Figure  2  (cont.) 


Data  base  management  system 

o  File  handling  capabilities  f 

o  Report  generators 

3.  Data  Communications 

Protocols  supported 

Emulation  as  remote  job  entry  terminal  to  large  computers  (e.g.,  2780  and 
3780  emulation) 

Terminal  communications  -  method,  overhead,  ease  of  expansion 

4.  Application  Software 

(Features  and  functions  from  user  requirements) 

5.  Personnel/Organization 

Staffing  support  for  operations 

o  Data  entry,  batch  controls 
o  Report  distribution,  inquiry 
o  Systems  programming 
o  Management 

Support  of  development,  maintenance  and  enhancement 

o  Management 
o  Applications  programming 
o  Systems  analysis 

o  Data  administration 

Support  for  installation 

o  Program  conversion  (if  any) 
o  Data  conversion  (if  any) 
o  Pilot/parallel  installation 
o  Cabling/wiring/building  modifications 
o  Training 
o  Forms  design 
o  Documentation 
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3.  Analysis  of  Available  System  Solutions 


o  Possible  Solutions 

At  this  point  effort  has  been  expended  to  develop  requirements  for  a 
computer  based  system.  A  general  solution  must  now  be  selected  for 
computerization.  Several  possibilities  are: 

Developing  a  system  internally  to  run  on  an  internal  computer  center; 

Acquiring  a  software  package  to  run  on  an  internal  computer  center 

Using  an  outside  timesharing  vendor  or  service  bureau  (the  vendor 
supplies  a  timesharing  computer;  users  access  the  computer  via 
terminals); 

Acquiring  the  minicomputer  and  software  from  a  turnkey  vendor; 

Acquiring  a  minicomputer  and  doing  development  internally. 

These  are  not  all  mutually  exclusive  or  inclusive.  As  an  example,  if  one 
acquired  a  software  package  and  had  it  modified,  then  the  project  might  be 
treated  as  development. 

In  comparing  the  approaches  to  computerization  generalization  is  risky. 
The  viable  iternatives  depend  on  characteristics  of  the  application  system 
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as  well  as  possible  constraints  such  as  management  policy  dictating  an 
approach,  a  tight  time  schedule  prohibiting  development,  lack  of  available 
resources  on  an  internal  computer  center,  etc. 

A  general  comparison  of  the  alternatives  -  internal  development, 
acquiring  a  software  package,  using  outside  timesharing  or  a  service 
bureau,  and  using  a  turnkey  minicomputer  approach  -  must  take  into 
account: 


costs  (development,  installation,  operation) 
schedule  to  develop 
ease  of  use 

future  increases  in  power  needed 
capability  to  isolate  functions 
need  for  local  contact 
vendor  viability 
ease  of  maintenance 
legal  negotiation  needed 
operational  responsibilities 
documentation  available 

Figure  3  contains  some  common  advantages  and  disadvantages  of  the 
alternatives.  It  is  important  to  remember  that  these  are  general  and  may 
not  apply  in  all  cases. 
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FIGURE  3.  Some  Frequently  Encountered  Advantages/Oisadvantages 
of  Computer  Alternatives 


Alternative 

Internal  development 
(minicomputer  or 
mainframe) 


Software  package 
on  internal  com¬ 
puter  center 


Outside  timesharing 
and  service  bureaus 
using  packages  or 
doing  development 


Turnkey  minicomputer 


Advantages 

Customized  solution,  no 
legal  negotiation,  better 
development  control,  staff 
gains  experience,  moderate 
operation  cost 


Low  development  acquisi¬ 
tion  cost,  tested  and 
demonstrated  software, 
documentation  available 


Ease  of  use,  communication 
network,  software  tools, 
specialized  data  bases, 
potentially  excellent 
service  level  by  vendor 
who  is  marketing  oriented 


Faster  development  time, 
organization  is  provided 
structure  around  applica¬ 
tion,  moderate  initial 
cost,  total  cost  more  cer¬ 
tain,  potentially  excel¬ 
lent  service  level  by 
vendor  who  is  marketing 
oriented 
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Disadvantages 

Longer  development  time, 
potential  risk  of  failure, 
higher  cost  of  development 
only  estimated  costs 
available,  costs  incurred 
even  if  failure 

May  not  meet  all  user 
needs,  legal  negotiation, 
dependence  on  external 
organization  (lack  of 
control) 

High  operational  unit 
cost,  less  control, 
lack  of  flexibility 
in  moving  software, 
dependence  on  external 
organization  (lack  of 
control) 

May  not  meet  all  user 
needs,  dependence  on 
external  support,  legal 
negotiation,  need  for 
operational  staff, 
potential  difficulty  in 
integrating  with  other 
systems,  dependence  on 
external  organization 
(lack  of  control), 
limited  increased  power 


o  Selecting  an  Approach 


In  order  to  make  the  decision  on  computerization  information  must  be 
collected  from  internal  groups  as  well  as  external  vendors.  Names  and 
information  on  time-sharing  vendors  can  be  obtained  through  the  Associa¬ 
tion  of  Time  Sharing  Users  or  internal  staff  members  who  have  responsi¬ 
bility  for  time-sharing  coordination.  Turnkey  and  software  firms  can  often 
be  identified  through  advertisements  or  from  minicomputer  hardware 
vendors.  Any  hardware  vendor  should  be  encouraged  to  recommend 
software  firms  so  that  software  needs  are  addressed.  The  number  of 
vendors  selected  should  be  limited  since  the  need  here  is  to  define  an 
approach. 

After  collecting  data  the  selection  is  made.  This  selection  may  not  be 
based  on  detailed  costs  and  schedule.  Such  data  may  not  be  available  in 
detail.  Rather  it  is  often  by  elimination  based  on  factors  such  ass 

Lack  of  application  software  packages  for  either  minicomputers  or 
data  centers 

Large  estimated  operat'onal  cost  from  using  an  external  service 

Limitation  of  hardware  and  communications  support  for  a  mini¬ 
computer 
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Difficulties  in  organizing,  coordinating,  and  managing  a  particular 
approach 

Lack  of  adequate  security,  controls  or  backup  with  a  particular 
alternative 

Risk  in  being  able  to  develop/modify  a  system  for  a  particular 
alternative 

Lack  of  single  responsible  coordination  point  for  hardware,  software, 
and  communications. 

The  remaining  steps  in  the  process  assume  that  a  minicomputer  approach 
has  been  taken. 


4.  Evaluating  and  Selecting  Among  Proposed  Solutions 


o  Data  collection 


Having  selected  a  minicomputer  approach  vendors  must  be  contacted  so  as 
to  solicit  formal  proposals.  The  number  of  vendors  solicited  obviously 
impacts  the  evaluation  time  and  effort.  In  a  formal  Request  for  Proposal 
effort  government  agencies  are  often  inundated  with  proposals.  However, 
it  is  equally  undesirable  to  deal  with  one  vendor  without  at  least  a  survey 
of  the  marketplace.  A  frequently  employed  approach  is  to  prescreen  the 
vendors  and  to  solicit  responses  from  at  most  three  to  five  vendors.  If, 
after  a  survey,  only  one  vendor  can  satisfy  the  requirements  negotiating 
the  contract  can  begin. 


What  information  should  be  given  to  the  vendor?  The  minimum  should 
include: 


User/system  requirements 


Schedule,  budget  restrictions 


List  of  information  needed  for  evaluation 
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-  Guidelines  to  make  proposals  uniform  and  complete  (e.g.,  sug¬ 
gested  outlines) 

-  Method  of  evaluation  of  proposals 

For  larger  systems,  questionnaires  would  be  developed  for  vendors  to 
complete.  This  could  include  a  list  of  all  requirements. 

The  list  of  information  needed  for  evaluation  includes  the  following: 

Relation  between  application  requirements,  as  given  in  request 
for  proposal  and  system  capabilities 

Complete  list  of  hardware,  system  software  and  application 
software 

Sample  or  proposed  contract 

-  Pricing  and  payment  terms 

List  of  current  users  who  can  be  contacted,  including  some  with 
similar  requirements 

Provision  for  growth/expansion/contraction 

Estimated  performance 
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Vendor  approach  to  maintenance  and  new  releases 


Correlation  between  proposed  system  and  user  system  require¬ 
ments 

Statement  of  vendor's  financial  condition 

Support  material  includes  brochures  and  manuals  which  help  explain  the 
vendor's  products.  These  may  be,  however,  of  limited  value.  Sales 
brochures  may  in  some  cases  be  misleading  while  manuals  may  be  too 
technical. 

Initial  Evaluation  of  Vendor  Responses 

The  evaluation  process  described  here  is  one  where  substantial  effort  is 
consumed  in  a  thorough  in-depth  analysis.  In  some  cases  the  scope  of 
evaluation  may  be  less,  due  to  the  limited  nature  of  an  application,  a 
scarcity  of  qualified  vendors,  or  other  factors. 

The  general  process  consists  of  the  following  steps: 

1.  Perform  initial  evaluation  and  elimination  of  vendors  thereby 
determining  finalists. 

2.  Conduct  in-depth  analysis  of  finalist  proposals. 


3.  Negotiate  contract  with  successful  vendor. 


Here  we  address  the  first  two  steps.  The  third  is  discussed  in  Section  3». 
The  objective  in  the  initial  evaluation  is  to  eliminate  vendor  proposals 
which  clearly  do  not  meet  the  stated  requirements.  Some  examples  of 
reasons  for  elimination  are: 

Inability  to  meet  specified  deadlines 

Lack  of  availability  of  function 

Proposal  does  not  satisfy  a  sufficient  number  of  the  user  require¬ 
ments. 

The  financial  or  staff  viability  of  the  vendor  is  questionable. 

Lack  of  compatibility  with  standards/hardware/software. 

The  initial  evaluation  does  not  usually  involve  visits  to  users  or  the  vendor 
sites.  These  come  later  after  the  finalists  have  been  determined.  The 
basis  for  the  initial  evaluation  are  the  proposal,  available  information  in 
magazines  and  references  such  as  Datapro.  Additional  information  may  be 
obtained  by  contacting  vendors  with  specific  questions.  Vendors  can  also 
be  encouraged  to  make  oral  presentations  of  their  proposals.  There  are 
some  reasons  for  avoiding  this  step  -  it  takes  time,  it  may  add  little 
information  and  it  may  increase  vendor  marketing  pressure.  In  large 
government  procurements  there  is  an  elaborate  scoring  process  for  evalua¬ 
tion.  In  minicomputer  business  selection  this  initial  evaluation  is  often  one 
of  elimination  of  proposals  which  do  not  qualify. 
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The  initial  evaluation  should  be  tentative  in  that  later  data  may  emerge 
which  disqualify  finalists  and  make  previously  eliminated  bidders  more 
attractive.  For  this  reason  no  formal  notification  should  be  given  until  the 
selection  of  the  winning  proposal. 

To  assist  in  the  evaluation,  checklists  of  user  requirements  are  helpful. 
The  same  applies  to  system  requirements  if  they  have  been  developed. 
Several  people  should  read  each  proposal  and  evaluate  it  on  the  basis  of  the 
checklist. 

It  is  possible  that  for  larger  minicomputer  applications  multiple  vendors 
may  be  selected.  If,  for  example,  one  wanted  inventory  and  general 
accounting  software,  there  might  be  three  vendors  involved  -  one  for 
hardware,  one  for  inventory  software  and  one  for  general  accounting 
software.  In  the  initial  evaluation  the  vendors  must  be  sorted  out  as  to 
what  parts  of  the  requirements  they  can  meet.  Then  a  combination  of 
vendors  can  be  constructed. 

o  Identification  of  finalists  -  in-depth  analysis 

To  reach  this  stage,  each  vendor  would  have  to  be  classified  as  meeting  the 
basic  user  requirements.  If  user  requirements  have  been  classified  into 
those  which  are  mandatory  and  those  desirable,  the  finalists  may  satisfy  all 
mandatory  requirements,  but  may  not  meet  all  desirable  requirements.  By 
this  point  questions  would  have  arisen  on  specific  capabilities  of  each 
finalist.  Some  examples  taken  from  a  recent  procurement  are: 
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When  will  the  vendor  support  word  processing? 

What  are  the  capabilities  of  the  file  management  utilities? 

What  are  the  vendor's  plans  for  memory  expansion? 

How  is  the  processor  network  coupled? 

Will  the  vendor  support  the  latest  version  of  COBOL? 

Will  the  machine  emulate  an  IBM  3780  or  some  other  RJE 
terminal? 

For  each  vendor  a  list  of  questions  and  issues  should  be  constructed.  These 
are  constructed  from  factors  where  vendor  products  characteristics  are  not 
known.  Answering  the  questions  successfully  does  not  mean  a  vendor  is 
selected.  It  merely  means  that  the  vendor  is  not  rejected. 

After  the  issues  and  questions  have  been  identified,  the  method  and  forum 
for  getting  answers  need  to  be  defined.  This  can  be  a  visit  by  the  vendor, 
but  if  possible  a  visit  to  vendor  facilities  is  preferable.  This  gives  an 
opportunity  to  make  many  informal  observations  of  the  vendor's  staff  and 
facilities.  Prior  to  a  visit,  the  vendor  representative  should  be  briefed  on 
the  issues  and  data  needed.  Data  might  include  financial  reports,  location 
of  support  offices,  support  staff,  and  expected  response  time  for  problems. 
The  representative  should  then  develop  an  agenda.  This  agenda  should  be 
reviewed  to  see  if  the  appropriate  topics  are  covered.  Since  topics  can  be 
covered  from  either  a  technical  or  marketing  view,  the  position  of  vendor 
personnel  should  be  ascertained.  Who  should  go  on  the  visit?  The  objective 
is  resolution  of  questions  on  one  visit.  There  should  be  an  evaluation  team 
of  at  least  two  -  one  representing  the  user  and  one  representing  technical 
support.  Multiple  visits  can  be  coordinated  on  the  same  trip  to  reduce 
travel  time. 


During  the  visit  the  vendor  will  likely  present  an  overview  of  his  products. 
Some  of  the  vendor  personnel  may  not  know  of  the  requirements.  After  an 
initial  general  presentation,  the  remainder  of  the  visit  should  address 
specific  issues.  A  brief  summary  of  the  requirements  should  be  presented 
to  provide  a  base  for  the  discussion.  Notes  should  be  taken  and  a  trip 
report  prepared  as  soon  after  the  visit  as  possible. 

Visits  to  user  sites  or  contacts  with  users  can  also  be  made.  These  visits  or 
contacts  should  identify  the  length  of  time  used,  overall  satisfaction,  any 
problems  in  support,  security,  and  maintenance,  ease  of  use,  reliability  of 
vendor  and  products,  efficiency  and  performances,  and  unexpected 
surprises. 

o  Evaluation  of  finalists 

After  the  visits  to  vendors  and  users,  the  evaluation  of  finalists  can  be 
done.  As  in  the  initial  evaluation,  several  approaches  can  be  used.  Vendors 
can  be  eliminated  individually,  based  on  their  visits.  Alternatively,  a 
scoring  system  can  be  employed.  Criteria  based  on  user  requirements  and 
performance  can  be  listed.  These  criteria  are  then  given  relative  weights. 
Each  proposal  is  scored  against  the  criteria.  The  scores  art  multiplied  by 
the  respective  weights  and  totaled.  The  proposal  with  the  highest  total 
weight  score  is  the  preferred  alternative.  There  are  several  limitations 
with  such  a  quantitative  approach.  It  assumes  a  certain  level  of  common¬ 
ality  between  alternatives  beyond  the  criteria.  However,  the  proposals 
may  be  very  dissimilar;  the  machine  architecture  and  languages  may  be 
different.  Therefore,  the  usual  approach  for  a  limited  number  of 
alternatives  is  to  proceed  by  elimination. 


To  highlight  possible  approaches  to  elimination,  some  examples  from 

recent  evaluations  in  other  companies  are  helpful.  In  these  cases,  vendors 

. 

were  eliminated  because  of: 

Lack  of  field  support  for  equipment  in  operating  locations. 

Inexperience  in  dealing  with  a  particular  software  applications 
area. 

-  Marginal  financial  condition  (major  officers  under  investigation  by 
SEC). 

Too  complex  hardware  and  software  subcontractor  relationships 
(too  many  subcontractors  creating  potential  managerial  and  tech¬ 
nical  problems). 

Too  expensive  and  complex  software  (overkill  of  problem  would 
have  created  problems  in  efficiency  and  maintenance). 

Future  support  of  product  line  questionable  (products  bid  were  old 
and  likely  to  be  replaced  soon). 


Limited  capacity  of  available  equipment  (e.g.,  disk  capacity, 
printing  capability,  processing  rate,  main  memory). 


Configurations  and  software  which  were  proposed  as  a  result  of 
misunderstanding  requirements. 

Lack  of  successful  installations  of  a  similar  nature. 

These  problems  cannot  be  overcome  by  vendor  promises  that  new  product 
announcements  are  imminent.  Frequently,  these  announcements  are 
deferred  due  to  market  or  technical  conditions.  In  other  cases,  they  are 
actually  part  of  marketing  so  that  with  sufficient  interest  they  will  build 
the  product.  However,  unless  it  is  from  a  major  vendor  or  can  be  seen  and 
tested,  the  product  should  not  be  assumed  to  exist. 


Negotiating  the  Contract 


Internal  legal  groups  can  provide  assistance  in  obtaining  a  suitable  contract. 
However,  it  helps  if  potential  users  have  knowledge  of  the  issues  that  recur 
repeatedly  in  negotiations.  This  will  facilitate  working  with  the  selected 
vendor  as  well  as  the  attorneys  involved.  This  section  discusses  contract  terms 
from  a  user  rather  than  a  legal  point  of  view.  It  does  not  replace  the  necessary 
legal  review  and  assistance.  The  contract  negotiation  effort  and  terms  must  be 
scaled  in  relation  to  the  product  or  service,  the  size  of  the  vendor  and  thin 
ability  to  negotiate.  It  should  be  pointed  out  that  no  contact  is  good  if  all 
parties  cannot  work  reasonably  well  together. 

What  can  be  negotiated?  Or,  what  terms  must  be  settled?  The  obvious  one  is 
price,  but  even  here  the  price  can  be  defined  in  terms  of  licenses  (fixed  term, 
perpetual),  purchase,  lease,  lease  with  option  to  purchase,  etc.  How  much  will 
maintenance  and  new  releases  cost?  All  options  must  be  spelled  out  in  detail. 
The  method  of  financing  depends  on  a  number  of  factors  including  useful  life  of 
system,  potential  salvage  value,  desire  to  use  investment  tax  credit  (1TC),  etc. 
A  safe  set  of  assumptions  is  a  two-three  year  life  with  little  or  no  salvage 
value.  The  users  would  then  frequently  move  up  to  other  equipment  with  more 
power. 

Price  is  not  all.  Here  is  a  partial  list  of  questions  which  must  be  answered  for 
hardware,  software  or  services. 


o  Maintenance  -  who  will  fix  it?  When?  What  happens  on  weekends  or  after 


hours  if  the  system  fails? 

o  Warranty  -  How  long?  What  happens  if  the  system  is  modified? 

o  Updates/later  releases  -  Are  you  asspred  of  getting  the  latest  releases  of 
the  system? 

o  Schedule  -  What  if  schedules  are  not  met?  Who  pays? 

o  Support  -  How  will  the  vendor  support  you  during  installation?  How  will 
the  system  be  kept  up  to  date? 

o  Rejection  -  Do  you  have  a  trial  period  in  which  you  can  reject  the  system? 

o  Multiple  sites  -  Suppose  you  later  wish  to  install  the  same  system 

elsewhere,  how  much  will  it  cost? 

o  Viability/fallback  -  If  the  vendor  goes  bankrupt,  what  happens  to  you  and 
your  system? 

o  Disputes  -  What  procedures  will  be  pursued  to  resolve  problems? 

o  Payment  -  Who  gets  paid?  When?  Under  what  conditions? 

o  Training  -  Who  will  do  the  training?  How  much  will  be  done? 
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o  Performance  -  How  will  the  system  performance  be  measured  after 
installation? 

o  Compatibility  -  What  is  the  vendor's  assurance  that  the  vendor's  product 
will  remain  compatible  with  the  user's  setting?  What  type  of  compatibility 
is  needed? 

o  Acceptance  -  Who  is  responsible  for  establishing  these  criteria,  data  col¬ 
lection,  and  evaluation?  Under  what  conditions  will  the  system  be 
accepted? 

o  Failure  -  How  are  the  vendor  performance  and  products  likely  to  fail? 
What  happens  if  they  fail?  Who  decides  when  failure  has  occurred? 

o  Contract  type  -  What  type  of  contract  is  most  appropriate  -  a  standard  one 
from  a  vendor,  a  current  contract  in  force,  or  a  new  contract? 

o  Trade-offs/ncgotiable  items  -  What  is  your  negotiating  room  on  each 
requirement?  What  trade-offs  are  you  willing  to  make? 

The  above  comments  and  questions  are  general.  They  apply  to  minicomputers 
themselves,  software,  and  services.  There  are  additional,  more  specific 
questions  which  need  to  be  asked  for  hardware  and  software.  These  are: 

o  Hardware 

Hardware  here  includes  computer  equipment,  system  software,  and 
support. 
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What  do  you  get? 


The  vendor  must  specify  the  hardware  and  system  software  by 
name,  number,  size,  etc.  The  hardware  configuration  is  needed 
along  with  the  requirements  of  the  software.  System  perform¬ 
ance  is  needed.  Specification  of  compatibility,  interface,  field 
modification  terms  are  necessary.  Manuals  can  be  referenced  and 
attached. 

What  is  the  support? 

What  is  the  support  for  cabling,  site  preparation,  physical  instal¬ 
lation,  power  support,  air  conditioning,  water  cooling,  humidity 
and  dust  control,  education,  training  materials,  test  time?  What 
other  resources  will  the  manufacturer  supply? 

What  will  it  cost? 

How  long  does  the  contract  run?  How  much  is  paid?  When? 
Under  what  conditions?  Can  funds  be  withheld  pending  evaluation 
of  vendor  performance?  What  are  the  taxes  and  transportation 
charges?  Who  gets  the  investment  tax  credit?  Is  credit  issued  if 
a  failure  occurs?  What  are  charges  for  spare  parts,  supplies, 
overtime  and  holiday  work,  training  and  consulting?  Is  there 
protection  against  price  increases? 
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Will  it  work? 


The  system  must  be  reliable  and  accepted  by  the  user.  Reliability 
means  the  estimated  mean  time  to  failure,  mean  time  between 
failures,  mean  time  to  repair  and  availability  of  a  certain  percent 
over  a  given  period.  Provisions  are  necessary  for  part  replace¬ 
ment,  backup  and  disaster. 

To  ensure  that  these  terms  afe  met  acceptance  must  be  done. 
The  acceptance  testing  period  ensures  operation,  performance, 
compatibility,  and  reliability.  Of  particular  interest  here  is  stress 
testing  where  a  system  is  subjected  to  a  high  number  of  active 
terminals. 

How  will  it  be  fixed? 

Will  it  be  fixed  at  the  user  site?  When?  How  long  after 
notification  of  failure?  What  support  must  be  given  to  mainte¬ 
nance  personnel?  Who  supplies  spare  parts?  Can  parts  be 
reconditioned  and  resold?  What  reporting  and  logging  procedures 
are  needed  for  malfunctions?  Under  what  conditions  will 
preventive  maintenance  be  done? 

When  will  you  get  it? 

For  computers  delivery  is  critical.  If  you  get  all  parts  but  one 
essential  part,  you  may  have  a  worthless  system  until  that  last 
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part  is  delivered.  Terms  must  be  set  on  early  or  late  delivery, 
delays,  and  installation  responsibility. 

What  are  your  rights? 

Can  you  add  hardware  to  it?  What  about  equipment  of  other 
manufacturers?  Can  you  upgrade  it  or  trade  it  in?  Can  you  move 
it  around?  Can  you  buy  it?  Under  what  terms? 

o  Software 

Software  here  includes  software  packages  as  well  as  services.  Such 
packages  and  services  come  as  a  part  of  acquiring  systems  from 
turnkey  vendors. 

What  do  you  get? 

In  addition  to  hardware  the  tunrkey  would  deliver  application 
software  coded  in  a  computer  language  along  with  documentation 
on  operating  and  using  it.  The  contract  should  specify  the 
deliverable  items  as  to  content,  number  of  copies,  software 
updates  and  software  enhancements.  The  contract  should  state 
the  system  software  necessary  to  support  the  application  and 
implementation  support  provided  by  the  vendor  at  no  additional 
cost. 
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Does  the  software  consume  reasonable  levels  of  resources?  The 
contract  should  specify  the  number  of  terminals,  type  of  use  and 
performance  that  can  be  anticipated. 

When  is  payment  made? 

The  payment  schedule  in  the  contract  depends  on  whether  the 
turnkey  vendor  is  going  to  modify  the  software  or  develop  new 
software.  If  there  is  to  be  development,  payments  should  be 
based  on  the  achievement  of  tangible  events  and  milestones. 
Damage  clauses  are  useful  here  to  permit  the  contract  to  be 
voided. 

For  a  software  package  a  common  financial  approach  is  usually  a 
one-time  fee  for  a  perpetual  license.  In  addition,  there  is  usually 
an  annual  maintenance  fee  which  provided  for  updates  and  new 
releases.  The  contract  should  protect  the  user  from  any  property 
tax  if,  in  the  future  software  is  declared  taxable. 

What  legal  protection  regarding  ownership  is  needed? 

The  vendor  must  state  in  the  contract  that  he  is  the  owner  and 
has  the  right  of  sale.  The  user  must  agree  to  protect  the  software 
from  willful  violations  of  copyrights,  patents,  etc.  "Save 
harmless"  clauses  are  needed  to  protect  users  from  accidental 


events. 


With  the  negotiation  and  signing  of  the  contract  project  planning  must  be  done 
to  monitor  vendor  work  and  to  ensure  that  user  requirements  are  satisfied  in 
the  end  products.  This  section  assumes  software  and  hardware  work  are  done 
by  a  vendor.  System  development  would  follow  internal  guidelines.  Elements 
of  a  project  plan  include: 


o  Schedule  -  activities  and  milestones  for  each  phase  (design,  develop¬ 
ment,  etc.);  persons  assigned,  equipment  needed;  budget 


o  Organization  control  -  a  plan  on  who  is  working  on  the  project  and 
their  interrelationships 


o  Documentation  -  content  outline,  user,  brief  description  of  all  docu¬ 
ments,  number  of  copies,  how  documents  will  be  maintained 


o  Training  -  the  plan  for  who  is  to  be  trained  in  what  means  during  what 
timeframe 


o  Review  and  reporting  -  the  method  for  reviewing  and  reporting  on  all 
project  work 


o  Change  control  -  the  approach  to  reviewing  and  approving  changes 


6.  Planning  and  Monitoring  the  Project 
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o  Testing  -  the  plan  to  test  each  part  of  the  system  as  well  as  the 
system  and  subsystems 

o  Data  conversion  -  the  type,  characteristics,  volume  and  responsibility 
for  converting  data  to  the  new  system 

o  Acceptance  test  plan  -  the  method  by  which  the  delivered  system  will 
be  tested  as  to  function  and  performance  and  accepted 

o  Installation  -  the  plan  for  installing  and  turning  over  the  minicomputer 
system  to  maintenance 

The  extent  of  the  plan  and  the  activities  depend  on  the  scope  and  nature  of  the 
application.  Obviously  a  small  turnkey  minicomputer  system  with  no  modifica¬ 
tions  requires  substantially  less  detail  than  a  multiple  minicomputer  network 
with  customized  software.  In  most  cases  some  tailoring  of  the  software  is 
needed. 

In  planning  care  must  be  taken  on  delivery  of  the  hardware.  In  general  it  should 
not  be  delivered  until  software  is  ready  to  run.  Otherwise,  it  sits  there  doing 
nothing  and  can  become  a  political  liability.  Also,  the  user  is  essentially  paying 
something  for  no  usable  function.  If  part  of  the  software  can  be  used,  then  it 
can  be  considered.  Not  taking  the  hardware  removes  pressure  from  accepting 
deficient  software  just  to  have  an  operational  system.  In  general  it  is  advisable 
to  take  these  possibilities  into  account  in  a  contract  section  on  acceptance. 


During  system  development,  users  must  commit  substantial  resources  to  assist 
in  the  design  and  review  vendor  work.  The  resources  include  the  right  people 
and  information.  It  could  involve  part  of  one  person's  time,  up  to  several  people 
full  time.  Failure  to  assign  appropriate  staff  may  result  in  project  delays  and 
misunderstandings  between  vendor  and  user  staffs. 

The  role  of  project  management  needs  to  be  emphasized  here.  With  multiple 
vendors,  someone  from  the  user  or  system  organizations  must  coordinate  and 
manage  the  project  activities.  The  duties  of  a  project  manager  include: 

Arranging  for  scheduled  and  periodic  review  and  project  meetings. 

Coordinating  vendor's  activities  to  ensure  compatibility  and  maintain  the 
integrity  of  the  schedule. 

Monitoring  vendor  activities,  budgets  and  handling  disputes. 

Depending  on  the  scope  of  effort,  the  project  manager  may  have  to  be  assigned 
full  time.  The  amount  of  time  depends  on  modifications  to  software,  schedule, 
overall  cost,  and  importance  of  the  project. 

What  happens  if  things  start  to  go  wrong?  How  can  this  be  detected  early? 
Here  are  some  signs  that  problems  may  arise: 

Project  staffing  by  the  vendor  changes  frequently  possibly  indicating  staff 
dissatisfaction,  low  priority  of  work,  etc. 
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Milestone  slippage  or  only  partially  satisfied  milestones. 


Communication  problems  between  users  and  vendor  staff. 

How  can  problems  be  uncovered  early?  By  regular  frequent  meetings  with  the 
vendor  technical  representative.  One  way  to  ensure  this  is  to  appoint  an 
implementation  review  group  that  meets  weekly  or  bi-weekly  and  reviews 
progress,  answers  questions,  and  resolves  problems.  The  use  of  measurable 
milestones  of  design  documents,  data  dictionaries,  program  specifications  and 
listings,  test  results,  etc.  should  be  emphasized.  An  updated  action  slate  of 
items  needed  to  be  resolved  should  be  established.  Doing  this  absorbs  more 
management  time  and  it  may  not  prevent  all  problems.  However,  problems  will 
be  surfaced  earlier  and  given  proper  attention.  The  review  group  can  also 
resolve  requests  for  changes  to  the  originally  agreed  upon  requirements. 

As  the  date  for  installation  of  the  system  approaches,  concern  and  questions 
arise.  After  ail  this  work  will  the  system  function?  One  way  to  minimize  this 
is  to  involve  users  in  training  and  operation  with  parts  of  the  system  that  are 
completed.  This  can  be  done  on  the  vendor  premises.  This  effort  cannot  be  too 
extensive  since  it  may  detract  from  the  completion  of  the  system. 
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Installation  and  Maintenance 


In  this  section  the  following  questions  are  addressed: 

o  How  should  the  site  for  the  minicomputer  be  prepared?  What  steps  are 
involved? 

o  What  is  the  managerial  and  administrative  structure  necessary? 

o  How  is  the  system  accepted  by  users? 

o  What  are  on-going  requirements?  What  controls  and  reviews  are  needed? 

These  will  now  be  examined  in  the  following  subsections. 

o  Site  preparation 

Physically  the  minicomputer  must  be  placed  in  a  proper  location.  There 
are  several  factors  to  consider  in  location  and  site  preparation. 

Terminals  must  be  within  a  specific  number  of  feet  of  the  computer. 
Distance  is  measured  in  cable  feet  not  shortest  distance.  The  range  is 
specified  by  the  manufacturer.  The  range  places  a  limitation  on  which 
floors  of  a  building  are  feasible.  Growth  should  be  considered  since 
the  cable  limit  is  likely  to  remain  for  some  time. 


Considerable  planning  and  effort  is  needed  in  laying  out  cable  paths 
and  specifying  how  much  cabling  is  to  be  done.  If  a  building  does  not 
have  utility  "tunnels",  then  there  may  be  considerable  expense  in  going 
through  walls,  ceilings,  etc.  Because  of  the  setup  cost  and  initial  cost 
it  is  usually  recommended  to  cable  locations  allowing  for  at  least  two 
years  growth. 

In  planning  the  computer  facility  consideration  needs  to  be  given  to 
forms/paper  storage,  output  distribution,  work  areas  to  perform 
maintenance  on  equipment,  and  staff  space,  ine  area  selected  may 
need  to  be  convenient  to  a  shipping/loading  dock  or  convenient  for 
user  access. 

Although  most  minicomputers  do  not  require  heavy  air  conditioning  or 
power,  provision  needs  to  be  made  for  times  (e.g.,  weekends,  holidays) 
when  building  air  conditioning  is  shut  down  or  when  it  is  reduced  to 
conserve  energy.  Allowance  for  backup  air  conditioning  and  power 
may  be  necessary. 

In  addition  to  the  site  being  prepared,  there  may  be  a  need  for  a 
backup  site  for  data  storage  in  another  building.  This  is  usually  a 
secure  room  where  backup  file  copies  and  program  listings  are 
retained  for  recovery  if  needed. 

Consideration  needs  to  be  given  to  security.  Equipment  needs  to  be 
protected  from  fire,  smoke,  water,  or  other  damage.  The  degree  of 
protection  depends  on  the  particular  user  situation.  Often  it  is 


sufficient  to  use  the  building's  protective  systems.  Related  to  this  is 
physical  security  to  protect  the  system  from  damage  by  people. 
Access  limitations  are  commonly  used.  Making  it  more  difficult  to  be 
around  the  machine  will  reduce  the  likelihood  of  damage  through 
inadvertent  or  intentional  acts. 

Administrative  Support 

A  minicomputer  requires  an  administrative  framework  which  is  as  compre¬ 
hensive,  but  more  limited  than  that  for  a  large  mainframe.  In  operations 
the  following  areas  must  be  addressed: 

Staff  support  -  number  of  shifts  during  which  the  machine  is  operated; 
support  needed  on  each  shift. 

Backup  procedures  -  timing  and  frequency  of  system  backup, 
checkpoint/ recovery /restart  procedures. 

Operations  documentation  -  procedures  to  document  an  application 
system  to  support  its  day  to  day  operation.  This  includes  data  input, 
job  production,  report  distribution,  recovery,  and  system  startup. 

Security  and  password  procedures  -  methods  for  assigning/deleting 
passwords. 

Accounting/auditing  -  procedures  for  auditing  transactions,  perform¬ 
ing  billing  and  job  accounting,  naming  conventions  for  files,  programs. 


Report  distribution  and  data  control  -  control  procedures  for  report 
distribution  and  information  archival. 


Allowance  for  growth  -  procedures  for  handling  increased  numbers  of 
users  and  applications. 

* 

Performance  monitoring  and  system  review  -  procedures  to  check  the 
utility  and  performance  of  hardware,  system  software,  communi¬ 
cations  and  application  software. 

Of  course  the  amount  of  attention  given  to  these  areas  depends  on  the 
applications  being  processed.  However,  it  should  be  emphasized  that  in  even 
simple  stand  alone  computer  equipment,  problems  may  occur  because  of  lack  of 
operational  procedures  and  lack  of  delegation  of  responsibility  to  a  "systems 
manager"  type  person.  When  this  happens  users  rapidly  lose  confidence  in  the 
system  and  revert  to  their  own  manual  procedures. 

The  above  discussion  highlights  a  common  myth  which  is  not  discounted  by 
minicomputer  vendors  -  that  minicomputers  usually  need  little,  if  any,  support. 
It  is  not  difficult  to  see  why  this  view  persists  -  since  adding  operational  costs 
to  the  other  system  costs  reduces  the  attractiveness  of  the  minicomputer 
alternative. 

o  Acceptance  testing 

After  delivery  of  the  system  and  user  training,  the  user  organization 
assisted  by  systems  support  carries  out  acceptance  testing  according  to  the 
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project  plan.  This  should  address  who  defines,  prepares,  executes,  and 
evaluates  test  cases  as  well  as  test  criteria.  In  acceptance  testing  the 
following  basic  questions  are  answered: 

Is  the  system  capable  of  performing  the  functions  identified  in  the 
user  requirements?  This  pertains  to  all  parts  of  input,  processing, 
reporting,  inquiry,  and  report  generation  capability. 

Does  the  system  satisfy  the  requirements  on  performance?  Per¬ 
formance  here  often  means  response  time  and  volume  of  information 
handled  with  the  system  under  stress.  Stress  can  be  generated  with  a 
large  number  simultaneous  active  terminals,  a  large  transaction 
volume,  or  by  a  heavy  job  load. 

After  acceptance  testing  there  is  either  acceptance  of  the  system  or 
additional  development  work  by  the  vendor. 

o  Maintenance  and  Enhancement 

As  the  application  software  is  used  in  production,  new  needs  arise. 
Initially,  after  a  system  begins  to  function  in  production,  most  effort  goes 
into  fixing  problems  in  the  system  that  were  not  detected  during  develop¬ 
ment.  After  this  period  most  demands  for  system  changes  are  for 
enhancements  -  adding  new  features  to  the  system.  These  enhancements 
include: 


Adding/modifying  reports 
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Adding  data  elements  to  files/reports 
Adding  inquiry  capability  at  terminals 


I f  these  activities  are  not  monitored  and  controlled,  the  time  and  expense 
can  rapdidly  escalate.  A  minimal  level  of  controls  are  suggested  to  ensure 
cost  control  and  system  integrity.  This  includes: 

Log  of  all  requests  for  changes  to  a  system  along  with  a  cost- 
justification  for  the  changes 

Recording  and  maintaining  copies  of  the  latest  version  of  files/ 
documents/source  code 

-  Retest  procedures  to  ensure  new  versions  of  systems  are 
functional  before  replacing  the  older  version 
Documentation  update  procedure  to  keep  user  and  operations 
documentation  current 


In  addition  a  periodic  audit  of  each  operational  system  is  recommended  to 
ensure  that  the  system  is  being  used  and  operated  periodically. 


Appendix  A:  Minicomputers  and  the  Minicomputer  Industry 

Traditionally,  minicomputers  were  defined  as  general  purpose  machines  whose  cost 
did  not  exceed  $100,000.  Today,  this  definition  is  shifting  as  the  price-performance 
ratio  of  machines  improves.  There  are  over  100  minicomputer  hardware  vendors  in 
the  marketplace.  Many  of  these  obtain  basic  parts  from  other  manufacturers  and 
then  package  and  market  the  systems  to  end  users.  The  leading  vendors  and  the 
percentage  of  market  share  are  shown  in  Figure  7.  Figure  4  shows  the  rising  number 
of  minicomputer  installations  by  market  category.  As  can  be  seen,  this  is  a  market 
which  is  very  competitive  and  in  which  IBM  holds  a  sizeable,  but  not  as  yet 
dominant,  market  share.  There  appears  to  be  an  increased  likelihood  of  a  shakeout 
of  vendors  as  the  market  matures,  as  the  chip  manufacturers  compete  (e.g.,  Texas 
Instruments),  and  if  IBM  increases  its  competitive  aggressiveness. 

Historically,  minicomputers  offered  fewer  capabilities  than  mainframes.  This  is  no 
longer  the  case.  Price  performance  improvements  and  competitive  pressure  have 
seen  the  emergence  of  a  variety  of  minis  which  support  mainframe  functions,  such 
ast 

o  Language  -  COBOL,  FORTRAN,  BASIC,  APL,  PASCAL 

o  Operating  Systems  -  Multi-tasking,  virtual  systems 

o  Memory  -  up  to  1-2  million  bytes  of  main  memory 

o  Peripherals  -  wide  variety  of  printers,  disks,  tapes,  diskettes 
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It  should  be  noted  that  the  most  common  language  is  BASIC.  Versions  of  COBOL 
are  often  subsets  of  those  available  on  mainframes. 


In  general,  minicomputers  can  operate  in  standard  office  environments;  some  can 
operate  in  harsh  environments  with  respect  to  temperature,  humidity,  and  dust. 
There  are  no  special  air  conditioning  or  water  cooling  requirements.  Most  minis 
require  only  standard  power  supplies. 


Minicomputers  here  are  usually  computers  which  can  be  operated  in  customer 
environments. 


Many  minicomputers  would  have  been  classified  as  mainframes  as  little  as  five  years 
ago  based  on  their  processing  power  and  capabilities.  Mainframe  manufacturers 
have  announced  and  introduced  low  end  mainframes  which  are  priced  as  minis  (e.g., 
IBM-4331).  In  short,  the  line  between  mainframe  and  minicomputer  has  become 
blurred  leading  to  some  confusion  and  uncertainty  among  potential  users. 


Compounding  the  variety  and  extent  of  products  and  vendors  is  the  emergence  of  a 
service/software  industry  tied  to  the  minicomputers.  To  encourage  sales  of 
hardware,  minicomputer  manufacturers  have  stimulated  development  of  application 
software  by  giving  software  companies  discounts  on  hardware.  This  provides  an 
added  profit  margin  to  the  software  company  and  solidifies  the  relationship  between 
the  two  organizations.  Two  terms  used  frequently  are  OEM  and  turnkey  company. 
OEM  (Original  Equipment  Manufacturer)  is  a  company  which  obtains  hardware  at  a 
discount  and  packages  it;  a  turnkey  company  is  a  company  which  offers  a  total 
solution  of  hardware,  application  software,  and  consulting.  Until  the  recent 
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announcement  by  IBM  making  the  Series/ 1  available  for  OEM  discounts,  IBM  ignored 
this  marketing  approach.  The  effect  of  this  position  has  been  to  somewhat  retard 
the  development  of  application  software  for  IBM  minis.  Sales  of  IBM  minis  may  be 
harder  to  make  because  of  the  cost  of  customized  software. 
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FIGURE  4:  Vendors  and  Market  Share  for  1978 
General  Purpose  Minicomputers* 


Digital  Equipment  (e.g.,  PDPI1,  VAX) 
Data  General  (e.g.,  NOVA,  ECLIPSE) 
Hewlett-Packard  te.g.,  HP  1000,  3000) 
Mod  comp 

IBM  (e.g.,  Series  I,  System  32) 

Perkin  Elmer 
Honeywell 

Computer  Automation 
Sperry  Univac 
Microdata 

General  Automation 


-  39.7% 

-  20.3% 

-  9.3% 

-  5.1% 

-  3.7% 

-  3.7% 

-  2.9% 

-  1.9% 

-  1.8% 

-  1.6% 
-  1.4% 


♦Source  is  Dataquest 


FIGURE  5:  Minicomputer  Installations  by  Market  Category  -  1978* 


Vendor 

Manufacturing 

Service  Indust. 

Educ. ,  Research 
Government 

Other 

Digit  Equip 

31% 

20% 

43% 

6% 

Data  Genl. 

42 

18 

37 

3 

Hewlett- Pack 

35 

19 

40 

6 

Modcomp 

13 

10 

70 

7 

IBM 

29 

51 

10 

10 

Perkin  Elmer 

30 

28 

36 

6 

Honeywell 

19 

44 

34 

3 

♦Source  -  Dataquest 
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What  is  the  target  audience  for  minicomputer  hardware/software/service  vendors? 
Raw  hardware  is  not  intriguing  to  many  end  users  unless  they  have  substantial 
internal  systems  capability.  The  time  to  build  the  software  and  the  cost  of 
construction  also  reduce  the  attractiveness  of  this  path. 

The  more  common  approach  is  to  propose  a  total  solution  -  the  turnkey  approach.  A 
package  is  attractive  -  it  works  now  or  soon;  it  is  tested;  costs  are  better  defined. 
These  features  appeal  to  many  users.  A  turnkey  system  also  can  give  users 
potentially  more  control  over  their  computing  environment.  This  can  be  a  mixed 
blessing.  There  may  be  substantial  operational  and  managerial  costs  and  risks  with  a 
turnkey  approach. 

How  is  marketing  performed?  Often  there  is  casual  contact  at  trade  shows  or 
meetings  between  vendors  and  potential  users.  Vendors  often  pursue  these  contacts 
with  vigor.  In  some  organizations  turnkey  vendors  represent  a  threat  to  systems 
groups.  They  may  take  away  business.  The  system  group  may  be  forced  to  absorb 
substantial  maintenance  and  enhancement  costs  after  a  turnkey  installs  a  system.  In 
previous  times  the  high  cost  of  such  systems  created  a  high  level  of  visibility  and 
attention.  This  is  no  longer  usually  true.  Systems  groups  today  have  more  work 
than  can  be  handled  with  their  resources.  In  many  situations  more  responsibility  is 
borne  by  the  end  user.  This  creates  a  need  for  a  minimum  level  of  expertise  in  user 
organizations. 


Applications  on  minicomputers  can  be  classified  in  several  ways  including: 


o  Single  application  -  The  mini  is  dedicated  to  a  single  purpose.  Examples  are 
controlled  areas  in  buildings  and  garages,  point  of  sale  systems,  in  super¬ 
markets,  banks,  etc.,  engineering  and  instrumentation  applications  (e.g.,  process 
control). 

o  General  purpose  computing  -  The  mini  functions  as  a  computer  to  provide 
general  timesharing  supports.  Users  write  their  own  programs.  There  are  no 
software  production  applications. 

o  Multiple  defined  applications  -  The  mini  supports  a  fixed  number  of  applica¬ 
tions.  Users  do  not  write  their  own  software.  An  example  is  a  minicomputer 
dedicated  to  accounting  functions  -  general  ledger,  accounts  payable,  accounts 
receivable,  payroll,  etc. 

o  Mixed  computing  -  The  mini  functions  include  both  general  purpose  computing 
and  a  defined  set  of  applications  operating  in  a  production  mode. 
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